Warmup at init time runs before Lightning moves the model to GPU,
so Triton cannot compile kernels there. Remove the calls entirely;
compilation happens naturally on the first real training step.

Also fix default glu_type to softsign_glu in both tasks.

Warmup at init time runs before Lightning moves the model to GPU,
so Triton cannot compile kernels there. Remove the calls entirely;
compilation happens naturally on the first real training step.

Also fix default glu_type to softsign_glu in both tasks.

- P1: keep use_fused_kernels opt-in (false default) for backward compat
- P1: split weight at midpoint not at K, supporting expansion_factor != 1
- P2: add N param (GLU output dim) separate from K (input/conraction dim)
- P2: save ctx.N for backward wrapper calculations

- VarianceTask: add missing on_fit_start warmup (mirrors AcousticTask,
  sweeps pitch_predictor and variance_predictor over denoise_fn /
  velocity_fn). Previously use_fused_kernels_variance patched blocks
  but never warmed the autotune cache.
- _test(): compare fused AND eager against a shared fp32 reference
  instead of fused-vs-eager fp16. fp16 eager itself deviates ~1e-2
  relative from fp32 at K=512 (different accumulation order), so the
  old absolute threshold conflated rounding with kernel bugs. New
  criterion: fused error <= 2x eager error.

Verified on RTX 2070 (sm_75, torch 2.12.1+cu130, triton 3.2.0):
- kernel test: fused error consistently BELOW eager fp16 error
  (fp32 accumulators), K=256/512/1024 fwd+bwd all pass
- integration test: block fwd diff 1.95e-3, grad diff 2.20e-3
- eval-mode fallback matches train-mode fused output
- deepcopy safety: copied block uses own weights (stale-closure fixed)
- fallbacks: bias=None, CPU, fp32 (one-time warning), bf16-on-Turing
- simulated no-Triton import: module loads, eager fallback works
- warmup: no_grad forward-only, no grads created; full autocast fp16
  training step through patched LYNXNet2 works

If the modules.kernels.integration import fails, rank_zero_info (imported
on the following line inside the same try) is also unbound; import it
locally in the except clause like variance_task does.

…ory trick

Eager (common_layers.py):
- SoftSignGLUFunction: ATanGLUFunction-style custom backward.
  softsign'(x) = (1-|softsign(x)|)^2, so both partials are precomputable
  in forward; backward is two pure multiplies, saves one tensor vs naive
  autograd. SoftSignGLU now uses it in training mode.
- DoubleSoftSignGLU: y = softsign(out) * softsign(gate). softsign applied
  to the whole Linear output then split (elementwise => equivalent).
  Custom Function precomputes both partials into one [.., 2N] buffer.
- lynxnet2: register glu_type 'double_softsign_glu'.

Kernel (fused_linear_softsign_glu.py):
- IS_DOUBLE constexpr on fwd + bwd-elem kernels; Triton compiles two
  specializations, zero overhead in the single-gate path.
- fused_linear_softsign_glu(x, w, b, is_double=False) public API;
  eager fallback handles both modes.
- integration.py: _FUSABLE_GLU_TYPES = (softsign_glu, double_softsign_glu).

Verified on RTX 2070:
- eager Functions vs naive autograd in fp64: max diff < 2e-15 (both)
- double-mode kernel vs fp32 reference: fused error 2-5x SMALLER than
  eager fp16 (fwd 3.2e-4 vs 1.8e-3) — fp32 accumulators
- single-gate regression: unchanged, all pass
- block integration both modes: fwd/grad diff ~2e-3, eval fallback exact

One switch for both acoustic and variance training. The original
rationale for a separate variance key ('backbones too small to benefit')
did not hold up in benchmarks: at 24k frames/batch the variance backbone
gains 1.35x (single) / 1.62x (double softsign). The per-predictor
glu_type check already prevents patching non-softsign backbones, so the
extra key only added confusion. base.yaml comment now documents the
actual trade-off (benefit scales with max_batch_frames).